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1. INTRODUCTION 


1.1 SCOPE 

This standard establishes a Space Generic Open Avionics Architecture (SGOAA) interface 
model and the requirements for applying this model to the development of spacecraft core 
avionics systems. (This version of the SGOAA standard primarily addresses the general 
avionics processors and their interfaces. Internal interfaces for special avionics processors 
and embedded processors require further definition.) 


1.2 PURPOSE 

The purpose of this standard is to provide an umbrella set of requirements for applying the 
generic architecture interface model to the design of a specific avionics hardware/ software 
system. This standard defines a generic set of system interface points to facilitate 
identification of critical interfaces and establishes the requirements for applying appropriate 
low level detailed implementation standards to those interfaces points. The generic core 
avionics system and processing architecture models provided herein are robustly tailorable 
to specific system applications and provide a platform upon which the interface model is to 
be applied. 

1.3 APPLICATION GUIDANCE 

This standard is intended to be used by both avionics system designers and avionics system 
implementors in the development of open systems architectures for avionics. The system 
under design shall be expressed in the context of the System Architecture and Generic 
Processing Architecture as defined in Sections 5.1 and 5.2.1. 2 respectively of this standard. 
The Architecture Interface Model shall be directly applied to identify the specific interfaces 
requiring application of lower level standards. The selection of specific lower level 
standards is dependent upon unique system requirements, but shall be conducted in 
accordance with the guidelines provided in Section 4.2. 

This architecture is scaleable and recursive, and can be applied to any hierarchical level of 
hardware/software processing system, as discussed in Section 6.6. 
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1.4 BACKGROUND 


Development of a SGOAA that satisfies the Portable Operating System Interface (POSDO 
reference model [POSIX91], the Open System Interconnect (OSI) reference model [IS07498] 
and the definition of an open system architecture was initiated to aid in providing the 
following benefits to future space programs: 

• Provide the basis for establishing a set of specifications, standards and procedures 
that will become common to all systems used in simultaneously operational 
missions, e.g., to simplify interfaces between multiple vehicles (such as the 
shuttle and station) when performing a joint mission such as docking. 

• Ensure that future avionics systems can be upgraded and maintained with 
minimal redesign impact to the existing avionics system by establishing the 
interfaces required to enable modular replacement of hardware and software. 

• Promote availability of multiple sources of needed avionics software and 
hardware by defining standard interfaces. 

• Provide a pool of hardware and software modules for multiple program re-use by 
defining standard interfaces and promoting hardware and software reuse and 
commonality. 

• Insure access to the architecture and its design documentation for any vendor or 
agency desiring to propose new uses and applications, and to facilitate 
competition to contain cost growth. 

A complete description of the SGOAA development model, technical considerations and 
application examples is contained in the technical guide [WRA93]. 
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2. APPLICABLE DOCUMENTS 


The following documents provide additional supplemental material applicable to this 

standard. They provide additional requirements or expand on requirements from this 

standard for generic open architectures. 

2.1 STANDARDS 

PS07498] "Information Processing Systems - Open Systems Interconnection - Basic 

Reference Model", First Edition, International Standards Organization, 
October 1984. 

[POSDC91] "Draft Guide to the POSDC Open Systems Environment", P1003.0/D14, 

IEEE Computer Society, November 1991. 

[SYSB-1] "Systems Engineering", El A Engineering Bulletin SYSB-1, Electronics 

Industries Association (El A), December 1989. 

2.2 SPECIFICATIONS 

2.2.1 GOVERNMENT SPECIFICATIONS 

[JSC 31000] Space Station Projects Description and Requirements Document, Vol. 3, 

Rev G, 4 April 1991. 

[SSP 30235] Space Station Program Glossary, Acronyms and Abbreviations, CR 
BB007008A, No date 

[PAVE PILLAR] "Architecture Specification for PAVE PILLAR Avionics", SPA-90099001 A, 
Aeronautical Systems Division, USAF, January 1987. 


2.2.2 CONTRACTOR SPECIFICATIONS 
2.3 OTHER PUBLICATIONS 

[BOE91] Flanagan, Rich and Van Ausdal, Art, "SATWG Flight Data System 

Architecture Specification Outline" briefing, 25 October 1991 

[BOOCH87] Booch, Grady, "Software Engineering with Ada", 2nd Edition, Benjamin 
Cummings Publishing Comp., 1987. 
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[GD90A] 


[LAP90] 


[WRA93] 


General Dynamics "Space Avionics Requirements Study", 21 October 1990, 
Contract NAS8-37588, TD006 Presentation Package, as briefed to the 
SATWG 

Laprie, J. C., "Dependability: Basic Concepts and Terminology", J. C. Laprie 
- Editor, Published by International Federation for Information Processing 
(IFIP) Working Group 10.4 on Dependable Computing and Fault 
Tolerance, December 1990. 

Wray, R. B. and Stovall, J. R., "Space Generic Open Avionics Architecture 
(SGOAA) Reference Model Technical Guide", Job Order 60-430, Contract 
NAS9-17900 for the JSC, NASA CR-188246, LESC-30347-A, April 1993. 
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3. DEFINITIONS 


Definitions are taken from the [POSIX91] or [LAP90] where applicable or otherwise 
established as shown. 

3.1 APPLICATION 

Application is defined as the use of capabilities (services/ functions) provided by an 
information system specific to the satisfaction of a set of user requirements. [POSIX91] 


3.2 APPLICATION PLATFORM 

Application Platform (AP) is defined as the set of resources that supports the services on 
which an application or application software will run. Also known as a host platform. 
[POSDC91] 

3.3 APPLICATION PROGRAM INTERFACE 

Application Program Interface (API) is defined as the interface between the application 
software and the application platform, across which all services are provided. [POSIX91] 

3.4 APPLICATION SOFTWARE 

Application Software is defined as software that is specific to an application and is composed 
of programs, data and documentation. Application software has uniquely defined 
interfaces. [POSIX91] 

3.5 ARCHITECTURE 

Architecture is defined for this standard as the structure of Application Software, API, AP, 
and External Environment Interfaces (EEIs) which describe the organization and interfaces 
of a system. 

3.6 AVAILABILITY 

Availability is a measure of the probability that a designated system will delivery the correct 
service when called upon at any random point in time. [Adapted from LAP90} 
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3.7 AVIONICS SYSTEM 


Avionics System is defined for the purpose of this standard as the set of all electronic and 
processing based subsystems on a space vehicle, including all hardware, software and other 
electronics needed to control and operate the space vehicle. It is the collection of system 
elements and allocated capabilities that provides the coordinated functionality for end-to- 
end processing in handling the information needed to interface the space vehicle's major 
components, to control its interaction with its environment, and to respond to human 
commands. (Adapted from [JSC 31000]) 

3.8 COMMUNICATION INTERFACE 

Communication Interface is defined as the boundary between application software and the 
external environment, such as application software on other host platforms, external data 
transport facilities and devices. The communications interface may be internal to one space 
vehicle or across multiple space vehicles. [POSIX91] 

The services provided are those whose protocol state, syntax and format all must be 
standardized for interoperability. 

3.9 COMPONENT 

Component is one of the parts resulting when an entity is decomposed into constituent 
parts. 

3.10 CONTINUITY 

Continuity is defined to mean that requirements changes are proportional to design 
changes, i.e., that changes in the requirements will propagate into changes of the same order 
of magnitude in the design. 

3.11 CONTROL SYSTEM 

Control Subsystem is an application which selects and implements alternative actions based 
on a-priori criteria or real time guidance. 
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3.12 CORE AVIONICS 

Core Avionics is defined as the control subsystems and the supporting avionics (hardware 
and software) needed to enable these control subsystems to function. Core avionics include 
the controls for each of the traditional space avionics hardware subsystems (such as 
Guidance Navigation and Control (GN&C) and Communications and Tracking (C&T)). 

The avionics hardware sensors and effectors are outside the core avionics boundary. 


3.13 DATA 

Data are the sensor outputs to the system, input to applications from the system, output 
from applications to the system, input to crew or operations control elements from the 
system, outputs from crew or operations control elements to the system. Data may include 
commands. 


3.14 DATA BASE MANAGER 

Data Base Manager is the control subsystem which manages structured data files, file 
transfers and file redundancy management. 

3.15 DATA PROCESSING SYSTEM 

Data Processing Subsystem is an application subsystem providing data processing services. 
Data processing subsystems do not perform control subsystem functions. 

3.16 DATA SYSTEM 

Data System (for example the Space Data System - (SDS)) is a network of data system 
services, onboard computational resources, data storage, and human-machine interface 
devices which provide onboard command and control, data transmission, 
computation/processing, and operating application software to support a space vehicle's 
users (crew and controllers), interfacing systems, applications and subsystems. 


3.17 DATA SYSTEM SERVICES 

Data System Services (for example the Space Data System Services - (SDSS)) is a service 
subsystem with a generic functional architecture designed to provide a comprehensive set 
of services to all vehicles and subsystems. 
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3.18 DATA SYSTEM MANAGER 

Data System Manager is the control subsystem which manages the housekeeping and status 
control services for the SDSS. 

3.19 DECOMPOS ABILITY 

Decomposability is defined to mean requirements can be broken into smaller pieces with 
potentially simpler solutions or at least better understanding and a capability for further 
decomposition as needed. 

3.20 DEGRADED MODE 

Degraded mode is a system condition wherein some system elements (such as hardware, 
software, human, or procedural) are sufficiently unhealthy that the system cannot operate 
normally. 

3.21 DEPENDABILITY 

Dependability is defined as the trustworthiness of an avionic system such that reliance can 
justifiably be placed on the service it delivers. Depending on the application^) intended for 
the system, different emphasis may be put on different facets of dependability, i.e. 
dependability may be viewed according to different, but complementary, properties, which 
enable the attributes of dependability to be defined: 

• with respect to the readiness for usage, dependable means available; 

• with respect to the continuity of service, dependable means reliable; 

• with respect to the avoidance of catastrophic consequences on the environment, 
dependable means safe; 

• with respect to the prevention of unauthorized access and/or handling of 
information, dependable means secure. (Derived from [LAP90]). 


3.22 DIRECT INTERFACE 

Direct Interface is defined as the connection between an entity sending or receiving data 
with another entity receiving or sending data for transmission of the same data along the 
routing path associated with moving data from the source of the data to the end user of the 



data. Data is used by an entity in a direct manner if it passes the data on without changing 
the data; thus, for example, network operating systems are direct interfaces between 
applications when they package or unpack data and send it to another network node. 

3.23 DISTRIBUTED SYSTEM 

Distributed System is a collection of computers, memories, buses and networks that are 
concurrently operating in a cooperative manner and communicating with each other. 


3.24 END-USER 

End-user of data is the last entity which makes a significant transformation, conversion or 
operation on the data. 

3.25 ENTITY 

Entity is an abstract element that represents an object in the real world, its data attributes 
and essential services with their respective performance and quality characteristics. 

3.26 E RROR 

Error is defined to be that part of the system state which is liable to lead to subsequent 
failure. [LAP90] 

3.27 ERROR PROCESSING 

Error Processing is defined to be the actions taken in order to eliminate errors from a 
system. Error processing is error detection followed by either error recovery or error 
compensation. Error recovery replaces an error-free state for the erroneous one. Error 
compensation uses the redundancy of the state to enable the delivery of an error free service 
from the erroneous (internal) state. [LAP90] 

3.28 EXTERNAL ENVIRONMENT 

External Environment (EE) is defined as a set of external entities with which the application 
platform exchanges information. These entities are classified into the general categories of 
human users, information interchange entities and communication entities. [POSIX91] 
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3.29 EXTERNAL ENVIRONMENT INTERFACE 

External Environment Interface (EEI) is defined as the interface between the application 
platform and the EE across which information is exchanged. The EEI is defined primarily in 
support of system and application interoperability. This interface consists of 
human/computer interaction services, information services, and communications services. 
[POSIX91] 

3.30 EXTENSIBILITY 

Extensibility is the ability of an architecture to be extended or adapted to new conditions, 
changes in specifications or new technologies. 


3.31 FAILURE 

Failure is defined as a deviation of the delivered service from the specified service, where 
the service specification is an agreed description of the expected function and/or service. 
[LAP90] 

3.32 FAULT 

Fault is defined as the adjudged or hypothesized cause of an error. [LAP90] 

3.33 FAULT TOLERANCE 

Fault Tolerance is defined as providing a service complying with the specification in spite of 
faults. Fault tolerance is carried out by error processing and fault treatment. Error 
processing is aimed at removing errors from the system state, if possible before failure 
occurrence; fault treatment is aimed at preventing faults from being activated -- again. 
[LAP90] 

3.34 FAULT TREATMENT 

Fault Treatment is defined to be the actions taken in order to prevent a fault from being re- 
activated. The first step in fault treatment is fault diagnosis, which consists of determining 
the cause(s) of error(s), in terms of both location and nature. This is followed by fault 
passivation, which prevents the fault from being activated again. If the system is no longer 
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capable of delivering the same service as before, then a reconfiguration may take place. 
[LAP90] 

3.35 FLIGHT CRITICAL FUNCTION/INTERFACE 

Flight Critical Function is a function or interface which, if it fails, could cause loss of vehicle 
control resulting in loss of the vehicle and, if present, crew. The function or interface is 
characterized by the presence of hard deadlines (usually in the range of milliseconds), where 
missing a deadline is a failure. 


3.36 FUNCTION 

Function is an action/ task that the system must perform to satisfy customer and end user 
needs. Control of mission critical functions may require hard deadlines, where missing a 
deadline is a failure. 

3.37 GENERIC ARCHITECTURE 

Generic Architecture is an architecture where the elements of the architecture do not 
depend on any one mission or program for their definition. The elements of a generic 
architecture can be tailored to apply to many different missions and programs. 

3.38 HUMAN/COMPUTER INTERFACE 

Human/Computer Interface is the boundary across which direct interaction between a 
human being and the application platform take place. 


3.39 INTERFACE 

Interface is the shared boundary between two functional units, defined by functional and 
other physical characteristics, as appropriate. 

3.40 INTEROPERABILITY 

Interoperability is defined as the ability of two or more systems to exchange information 
and to mutually use the information that has been exchanged. [POSIX91] 
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3.41 LOGICAL INTERFACE 

Logical Interface is defined as the requirements associated with establishing a data 
interchange interface between a source of data and the end user of the data. The end user of 
the data must be identified to include the requirements for the data and the source 
supplying the data must also be identified. Data routing is transparent to logical interface 
entities. Routing of the data should not be a concern to the source and end user b ecause the 
routing (i.e., direct requirements) is transparent to these entities. 

3.42 MISSION CRITICAL FUNCTION/INTERFACE 

Mission Critical Function or Interface is any function or interface which, if it fails, results in 
an incomplete mission, a mission abort or a loss of payload. 

3.43 MISSION READY MODE 

Mission Ready Mode is a system condition wherein all system elements, including 
hardware, software, human and procedural, are available to enable the system to perform 
its intended function and the current mission for which it is intended. 

3.44 MODE 

Mode is a predefined set of hardware and software configurations, and associated 
procedures used to organize and manage the conditions of operation for an avionics 
system's behavior, as planned, pre-planned or directed by a human. 

3.45 MODULAR ARCHITECTURE 

Modular Architecture is an architecture composed of discrete components such that the 
design of one component depends only on the interface to other components, not on their 
internal design. A modular architecture is decomposable, understandable, protected, has 
continuity and is organized in a robust structure. It is desirable that a change in one 
component has minimal impact on other components. (Adapted from [SSP 30235]). 
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3.46 NETWORK SERVICES MANAGER 


Network Services Manager (NSM) is a control subsystem which manages peer-to-peer 
communication between application software running on distributed processing elements 
communicating over a network. 


3.47 OBJECT 

Object is something perceptible to the sense of vision or touch or to the mind. 

3.48 ONBOARD HEALTH MANAGEMENT 

Onboard Health Management is defined as the hardware and software used to monitor and 
control on board Avionics System resources to prevent or respond to system failure. This 
includes the ability to efficiently monitor, checkout, and test the Avionics System, Core 
Avionics, and related non-avionics subsystems before, during, and after operation, as 
applicable. Onboard health management supports, as required, reconfiguration of Avionics 
System resources to prevent catastrophic failure. 

3.49 OPEN FORUM 

Open Forum is defined as the review of a subject in a public consensus process. 

3.50 OPEN SPECIFICATION 

Open Specifications are defined as public specifications that are maintained by an open, 
public consensus process to accommodate new technologies over time and that are 
consistent with international standards. The public consensus process for open 
specifications must be maintained and accepted by an open forum. [POSDC91] 

3.51 OPEN SYSTEM 

Open System is defined as a system that implements sufficient open specifications for 
interfaces, services, and supporting formats to enable properly engineered application 
software: [POSIX91] 

• to be ported with minimal changes across a wide range of systems 

• to interoperate with other applications on local and remote systems 

• to interact with users in a style that facilitates user portability 
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3.52 OPEN SYSTEM INTERFACE STANDARDS 

Open System Interface Standards are standards that provide for open specifications of open 
systems. 

3.53 OPEN SYSTEM APPLICATION PROGRAM INTERFACE 

Open System Application Program Interface is defined as a combination of standards-based 
interfaces specifying a complete interface between application software and the underlying 
application platform. This is divided into the following parts: [POSIX91] 

• Human /Computer Interaction Services API 

• Information Services API 

• Communication Services API 

• System Services API 

3.54 OPEN SYSTEMS ARCHITECTURE 

Open Systems Architecture is defined as an architecture for an open system using open 
specifications. It consists of a structure of interconnected functional subsystems (i.e., black 
boxes) using non-proprietary communications, based on open specifications for interfaces, 
and providing high level standard services. The interface between the application software 
and the underlying application platform must be based on an Open System Application 
Program Interface. To be open, the architecture must be extensible through the addition of 
subsystems, services and resources following open specification rules. 


3.55 OPEN SYSTEM ENVIRONMENT 

Open System Environment (OSE) is defined as the comprehensive set of interfaces, services 
and supporting formats, plus user aspects for interoperability or for portability of applica- 
tions, data, or people, as specified by information technology standards and profiles. 
[P05IX91] 

3.56 OPERATING SYSTEM 

Operating System (OS) is the layer of software that isolates services and application software 
from the application platform hardware element. The OS provides services for at least 
management, allocation, and deallocation of the processor, memory, timing and 
input /output (I/O) processing resources for application and service software. 
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3.57 OPERATIONALLY READY MODE 

Operationally Ready mode is a system condition wherein most system hardware, software, 
human and procedural elements are functioning correctly, but not all subsystems are 
configured as needed for a mission to be performed. 

3.58 PLATFORM 

See Application Platform definition. 

3.59 PORTABILITY 

Portability is defined as the ease with which software can be transferred from one platform, 
application or information system to another. [POSDC91] 

3.60 PROFILING 

Profiling is the process of selecting a set of one or more base standards, and where 
applicable, the identification of chosen classes, subsets, options, and parameters of those base 
standards, necessary for accomplishing a particular function. (The profile selection process 
is discussed in section 6 of [POSIX91]). 

3.61 PROTECTION 

Protection is defined to mean that the architecture will limit the effect of abnormal 
conditions in design elements at run-time to just the affected modules or as a minimum 
will limit the propagation of abnormal conditions. 

3.62 RED-TAGGED MODE 

Red-tagged mode is a system condition wherein sufficient system hardware, software, 
human or procedural elements are failed that the system cannot operate at all. 


3.63 RELIABILITY 

Reliability is a measure of the probability that an item will deliver the correct service under 
specified conditions without failure, for a specified period of time. 
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3.64 REQUIREMENTS ARCHITECTURE 


Requirements Architecture is an architecture that can be tailored for design implementa- 
tion based on actual system requirements. 


3.65 ROBUSTNESS 

Robustness is the measure of a system's ability to support continued functioning under 
abnormal operating conditions. 


3.66 SAFETY CRITICAL FUNCTION 

Safety Critical Function is any function which has an associated condition, event, operation, 
process, equipment or system (including software) with the potential for catastrophic injury 
or damage to onboard systems, life, or environment, (adapted from [SSP 30235] and [LAP90]. 

3.67 SERVICE 

Service delivered by a system is its behavior as it is perceived by its user(s). 

3.68 SERVICE SUBSYSTEM 

Service Subsystem is service software on an application platform, which provides 
transparent services to the using control or data processing subsystem. 

3.69 SOFTWARE 

Software is defined as the programs, procedures, rules, and any associated documentation 
pertaining to the operation of a data processing system. [POSDC91] 

3.70 SOURCE 

Source is the originator of data passed across a logical interface. 

3.71 SPACE DATA SYSTEM 

See Data System definition. 
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3.72 SPACE DATA SYSTEM SERVICES (SPSS) 

See Data System Services definition. 


3.73 SPACE GENERIC OPEN AVIONICS ARCHITECTURE fSGOAA) 

SGOAA is defined as the target open architecture standard being developed to provide an 
umbrella set of requirements for applying a generic architecture interface model to the 
design of specific avionics hardware/software systems. This standard defines a generic set of 
system interface points and establishes the requirements for applying appropriate low level 
detailed implementation standards to those interfaces points. The generic core avionics 
system and processing hardware architecture models provided by the standard are robustly 
tailorable to specific system applications and provide a platform upon which the generic 
interface model is to be applied. 

3.74 INPUT/OUTPUT DATA SERVICES MANAGER 

Input/Output Data Services Manager is the interface handling subsystem that manages the 
services that process requests for interaction between sensors, effectors, application software 
and other services. 

3.75 STANDARD 

Standard is a document established by consensus and approved by a recognized body, that 
provides, for common and repeated use, rules, guidelines, or characteristics for activities or 
their results, aimed at the achievement of the maximum degree of order in a given context. 

&Z£ STANDARDIZED PROFILE 

Standardized Profile is defined as a balloted formal, harmonized document that specifies a 
profile. [POSD01] 

3.77 SYSTEM 

System is defined as the composite of equipment, material, computer software, personnel, 
facilities and information/procedural data that satisfies a user need. [SYSB-1] 
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3.78 SYSTEM HARDWARE ARCHITECTURE 


System Hardware Architecture is an architecture consisting of the set of hardware resources 
in a configuration of distributed computers, memories, buses and network elements. 

3.79 SYSTEM SOFTWARE ARCHITECTURE 

System Software Architecture is an architecture consisting of the elements and interfaces 
between software components in a system. 

3.80 SYSTEM SERVICES SOFTWARE 

System Services Software is common software, independent of application software, which 
is needed to run application software and enable it to interface to data within a system or 
across the EEI. This is similar to the POSDC entity, system software, which is defined as the 
application independent software that supports the running of application software. 

3.81 TASK 

Task is defined as a software entity that is executed in parallel with other parts of a software 
program to perform an action. [BOOCH87] 

3.82 UNDERSTAND ABILITY 

Understandability is defined to mean all requirements related to a subject can be found and 
viewed together, and individually and jointly understood by the analysts and designers. 

3.83 USER 

User is another system (human or physical) which interacts with the target system. 
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4. GENERAL REQUIREMENTS 


The SGOAA shall [1] be used to determine the interface points and requirements for the 
control of, and information exchange between, onboard subsystems, support to the crew, 
and effective interfaces between onboard and offboard systems. In accordance with system 
requirements, a SGOAA compliant architecture shall [2] meet open standards criteria. A 
SGOAA compliant system architecture shall [3] provide data acquisition, data storage, data 
processing and data communication functions that interconnect architectural elements as 
shown in the functional interface diagram. Figure 4-1. Architectures developed in 
accordance with this standard shall [4] meet the following general requirements for 
developing new architectural elements and for using existing applications and mission 
elements. 

4.1 OPEN SYSTEMS REQUIREMENTS 

An architecture developed in accordance with this standard shall [1] satisfy the open systems 
architecture definition incorporated in this standard. The open architecture so developed 
shall [2] be capable of being readily expanded in functionality and performance without 
redesign or significant modification to the existing system. An architecture satisfying this 
standard shall provide information hiding, abstraction, inheritance, modularity, robustness 
and extensibility. 

Control subsystems may be decomposed into lower level subsystems. A control subsystem 
usually implements a unique avionics capability. These control subsystems may have 
flight, mission, or safety critical functions. 


4.2 LOWER LEVEL STANDARDS SELECTION 

Lower level standards developed by accredited standards development organizations 
(which use an open forum) shall [1] be preferred in selection over those standards 
developed by bodies using a closed forum. Lower level standards shall [2] be selected by the 
process of developing a standardized profile. Architecture specifications for which there is 
no draft or approved standard shall [3] not be selected. One of the driving requirements for 
selection shall [4] be selection of a standard that provides the full range of services required 
to satisfy the system applications. Other factors to consider in standards selection shall [5] be 
degree of openness in development, stage of completion, stability, compliance with national 
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Figure 4-1. SGOAA Functional Interfaces 







and international standards, degree of satisfying a SGOAA service need, consistency with 
the SGOAA and availability for implementation without restrictions. 

Preference shall [6] be given to existing mature standards, followed by emerging standards, 
and only if necessary, followed by new standards. The order of selection within these 
preferences is as follows: 

• Approved standards developed by (a) accredited international bodies, (b) accredited 
regional bodies and (c) accredited national bodies. 

• Draft standards developed by (a) accredited international bodies, (b) accredited 
regional bodies and (c) accredited national bodies. 

• Recognized de facto standards and specifications developed by nonaccredited bodies 
using an open forum. 

• Approved standards and specifications developed by nonaccredited international 
standards bodies using a closed forum. 

• Approved standards and specifications developed by nonaccredited national 
standards bodies using a closed forum. 

4.3 ARCHITECTURE FEATURES 

An Architecture prepared in accordance with this standard shall [1] provide the following 
features. 

4.3.1 REQUIREMENTS ARCHITECTURE 

An architecture prepared in accordance with this standard shall [1] be an architecture that 
can be tailored for design implementation based on actual system requirements. 

4.3.2 CRITICAL INTERFACES 

An architecture prepared in accordance with this standard shall support [1] flight, [2] 
mission and [3] safety critical functions and interfaces, as required. 
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4.3.3 NON-CRITICAL INTERFACES 


An architecture prepared in accordance with this standard shall [1] support non-critical 
support functions and interfaces, as required. 

4.3.4 RESOURCE CONTROL 

An architecture prepared in accordance with this standard shall [1] provide for control of the 
system resources that are used for control and information processing in onboard systems 
by use of system services software as requested by application software through a standard 
interface. 


4.3.5 COMMONALITY 

An architecture shall [1] be comprised of common hardware and software components to 
the maximum possible extent. 

4.3.6 INTERFACE STANDARDIZATION 

An architecture prepared in accordance with this standard shall [1] provide standard 
interfaces and shall [2] also allow user definable interfaces where no standards exist or 
standard is not applicable. Interfaces between hardware and other hardware entities shall [3] 
be based on standards. Interfaces between hardware and software shall [4] be based on 
standards. Interfaces between system services software and application software [5] shall be 
based on standards. The following interfaces shall [6] be prohibited in an architecture 
compliant with this standard: (1) direct, non-service task to task communications, and (2) 
applications to applications direct information exchanges, which bypass use of system 
services. 

4.3.7 CREW OVERRIDE 

For crewed vehicles, an architecture prepared in accordance with this standard shall [1] 
enable crew intervention, through multiple techniques, to safely override or inhibit 
automatic flight, mission or safety critical functions. For uncrewed vehicles, the 
architecture shall [2] enable ground control station intervention to safely override or inhibit 
flight, mission or safety critical functions. 
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4.3.8 ONBOARD HEALTH MANAGEMENT 


An architecture compliant with this standard shall [1] provide at least health management, 
status monitoring and warning capability to monitor critical functions in onboard systems, 
subsystems, components and crew and shall [2] provide avionics system level error recovery 
and fault treatment for non-critical hard deadline functions. Fault tolerance shall [3] be 
carried out by error processing and fault treatment. System service software built-in-test 
(BIT) to include error detection, processing and recovery and fault treatment shall [4] be 
incorporated into software control modules. Hardware built-in-test equipment (BITE) to 
include error detection, processing and recovery and fault treatment shall [5] be 
incorporated into hardware modules. Error processing and recovery and fault treatment for 
flight critical functions shall [6] be performed at the system services software and/ or 
hardware module level. The interface between hardware BITE and health and status 
applications software shall [7] be through standard software services. Error detection, 
processing and recovery and fault treatment shall [8] be timely enough to prevent loss of 
critical functions. 

At least two levels of health management, status and warning capability may be provided in 
compliant architectures: level 1 is application software prepared for the user's platform 
with knowledge of the mission, system and user goals. Level 2 is service software which 
utilizes standard health management capabilities (i.e., in Data System Services) as defined 
in paragraph 4.3.9.4 of this standard. 

On board health management that controls allocation of avionics system resources shall [9] 
be implemented in application software where knowledge of the mission or specific system 
is unique and cannot be entered into the table-driven health management Data System 
Services software . The interface between the reconfiguration hardware and the controlling 
application software shall [10] be through standard Data System Services software. 
Application software performing on board health management shall [11] be capable of 
overriding reconfiguration decisions made by fault tolerance functions provided in Data 
System Management under Data System Services. 

An architecture compliant with this standard shall [12] provide operating modes for at least: 
(1) mission ready, (2) operationally ready, (3) degraded, and (4) red-tagged. 
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4.3.9 DATA SYSTEM SERVICES 

An architecture prepared in accordance with this standard shall [1] include requirements for 
data system services. This shall [2] consist of at least requirements for input/ output data 
services management, network services management, data base management, data system 
management, and an operating system. 

4.3.10 GROWTH AND SPARE CAPACITY 

An architecture prepared in accordance with this standard shall [1] accommodate growth 
and spare capacity in data storage, processing throughput, network throughput, 
input/output and additional sensors/effectors as required by system documentation. 

4.3.11 MODULARITY 

An architecture prepared in accordance with this standard shall [1] be modular. 


4.3.12 SERVICE TRANSPARENCY 

An architecture prepared in accordance with this standard shall [1] be implemented with 
sufficient transparency that the user will have visibility into the operation of services, but 
not necessarily the implementation of services. 

4.3.13 TECHNOLOGY TRANSPARENCY 

An architecture prepared in accordance with this standard shall [1] be implemented with 
sufficient transparency that technologies applied to design can be upgraded without revising 
the architecture and without negative impact on the user. 

4.3.14 INTEROPERABILITY 

An architecture prepared in accordance with this standard shall [1] support interoperability 
by providing standard interfaces between multiple programs. 

4.3.15 DEPENDABILITY 

An architecture prepared in accordance with this standard shall [1] meet dependability 
requirements in a manner that supports standard interfaces, commonality, modularity and 
interoperability. Such an architecture shall [2] further satisfy the following subparagraphs. 
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4.3.15.1 Availability 

An architecture compliant with this standard shall [1] be designed to satisfy the specified 
Availability requirements of the designated system. 


4.3.15.2 Reliability 

An architecture compliant with this standard shall [1] be designed to satisfy the specified 
Reliability requirements of the designated item. 


4.3.15.3 Safety 

An architecture compliant with this standard shall [1] provide an interface not dependent 
upon avionics system specific safety features for application software that is required to be 
portable. 


4.3.15.4 Security 

An architecture compliant with this standard shall [1] provide an interface not dependent 
upon avionics system specific security features for application software that is required to be 
portable. 
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5. ARCHITECTURE INTERFACE DETAILED REQUIREMENTS 


The SGOAA model is based on partitioning between logical and direct requirements as 
illustrated in Figure 5-1. The model is established to include architectural functions, 
hardware, software and interfaces for all avionics systems. This SGOAA requirements 
description includes both system service software and applications software for the Space 
Data and Operations Control Subsystems. Interfaces in this model are valid for both one 
platform and multi-platform architectures on one or more vehicles. 

This model is to be used to define how system requirements are to be applied at the 
appropriate system level to determine the logical and direct interface points. System logical 
data flow requirements should be created for each client/server entity addressing the data 
attributes needed by that entity or needed to be provided for some other entity. The logical 
data flow requirements should identify the source of the data and the end-user needing the 
data, as well as the characteristic attributes required of the data. Logical data flow 
requirements should not be concerned with the mechanism for implementing the data 
interchange. Implementation related requirements for the interfaces are a direct interface 
issue relating to the mechanisms provided for flowing the data from the source to the end- 
user. Sources of the design requirements for the interfaces, application platform hardware 
and application platform services should be derived from the Applications Software 
requirements and their logical data attribute requirements based on the user's needs. 

5.1 SYSTEM ARCHITECTURE REQUIREMENTS 

The SGOAA System Architecture as shown in Figure 5-2 shall form the basis for creating a 
model of the system under development. 

System architecture models shall [1] consist of a functional definition of the types of 
processors and communications paths required. The model shown in figure'5-2 has three 
types of processors interconnected by two types of communications. This model only shows 
one of each type of hardware; the number of instances of each type of processor is variable 
depending upon system unique requirements and may range for 0 to n. For example, a 
centralized system architecture may look just like Figure 5-2, while a distributed system 
architecture may have multiple General Avionics Processor (GAPs), Special Avionics 
Processor (SAPs) and Embedded Processor (EPs). Either type of architecture may have many 
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Figure 5-2. System Architecture 



system interconnects and/or local interconnect mechanisms. More than one sensor and 
effector will usually be the rule in most non-trivial systems. 

The processors shown in the system architecture in Figure 5-2 are a GAP for general 
purpose processing, a SAP for specialized processing support (vector/massively 
parallel/ other), and an EP for the function of processing data within the sensor and effector 
devices. The sensors and effectors shown in the example may also interact directly with the 
main processors (the GAPs) or indirectly through EPs built into the sensors and effectors (if 
applicable). 

Communications paths illustrated are of three types: system interconnects such as core 
networks for interconnecting sets of general processors or nodes, local interconnects such as 
local buses for interconnecting EPs and SAPs with their supported GAPs and general 
purpose processing applications, and internal interconnects such as backplane buses. 

System models shall [2] follow the general format of Figure 5-2, but shall [3] be tailored to 
match individual system requirements, in particular the program’s application of sizing to 
the "system". 


5.2 ARCHITECTURE INTERFACE MODEL REQUIREMENTS 

An architecture compliant with the SGOAA Interface Model requirements shall [1] consist 
of six classes of interfaces as shown in Figure 5-3 and defined in Table 5-1. These classes are 
the levels of interfaces from hardware up to high level systems which are to be completely 
defined in an architecture developed in accordance with this standard. Definition of each 
interface class shall [2] be in accordance with the requirements contained in the following 
paragraphs. 

For flight and safety critical functions, the exchange of information for error processing and 
control shall [3] be restricted to classes 1,2, and 3. For mission critical functions, the 
exchange of information for error processing and control shall [4] be restricted to classes 
1,2,3/ and 4. For any critical functions or service function with hard deadlines, an 
architecture prepared in compliance with this standard shall [5] not allow the exchange of 
information for error processing across Interface Classes 5 and 6. Errors introduced by data 
transmission are removed at the lower interface class. The data itself, however, may still 
have errors if the source of the data was in error. Error processing on these data error may 
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Figure 5-3. Reference Architecture Interface Model 














Table 5-1 . Architectural Interface Classes 


CLASS 


DESCRIPTION 


Hard ware-to-Hard ware Direct : 


Class 1 hardware direct interfaces are the direct connections between different types of 
hardware such as needed to enable buses and communications links to address processors or 
needed to enable processors to address memory registers. 


Hardware-to-Operating System Extension Software Direct : 


Class 2 hardware to operating system extension software direct interfaces are the direct 
connections between hardware registers and operating system extension service software or 
other software performing that function, such as drivers needed to enable address registers 
to move data packets from hardware to system service software, and service drivers which 
can respond to the data packets. 


Operating System Services Software-to-Software (L ocal) Direct: 


Class 3 operating system service software to other software direct interfaces are the direct 
connections between operating system service code and other local software code sets, 
which enable operating system software to receive and interpret data packets, and pass 
them on to other software code which will process them locally. 


Data System Services Software-to-Data System Services Software Logical : 


Class 4 system service software to other system service software logical interfaces are the 
indirect connections which enable local service software to determine the address of the 
intended software in other local or remote locations which need the register data being 
stored and to pass the data appropriately. Enables the handling of logical data transfers 
from source to user service 


Data System Services Software-to-Applications Softw are Direct: 


Class 5 system service software to applications software direct interfaces are the direct 
connections which enable software service code to access and process data from local 
application software code. 


A pplications Software-to-Applications Software Logical : 


Class 6 applications software to applications software logical interfaces are the indirect 
connections which enable an application originating data to pass it to an application 
which needs to use the data, or enable an application needing data to determine the source 
from which the data must be obtained. These are logical data transfers from source to user. 
This interface provides the indirect connections that allow applications in different 
systems or in the same system to communicate, thus enabling applications software to 
interact across or within system boundaries to accomplish a mutual purpose. These 
interfaces may be applicable to applications executing in the same processor, in different 
processors in the same node or in different systems. 











take place in the application software, but it must be understood that such error processing 
reduces the portability of this Application Software. 

5.2.1 CLASS 1 ■ HARDWARE-TO-HARDWARE DIRECT INTERFACE 
REQUIREMENTS 

The ClaQQ l Hardware-to-Hardware Direct Interface shall [1] be defined in accordance with 
the three key aspects of the class 1 direct interface: the interface architecture, the generic 
processing external hardware architecture, and the general avionics processor internal 
hardware architecture. 

All types of error processing on data transmissions through the class 1 interface shall [2] be 
allowed. 

5.2.1 .1 Interface Architecture 

5.2.1 .1.1 Hardware to Hardware Direct Interfaces 

Hardware to hardware direct interfaces shall [1] be defined as shown in Figure 5-4. These 
interfaces consist of the nuts and bolts, chips and wires of the system architecture model 
described in paragraph 5.1. With regard to the model, this interface shall [2] consist of all the 
hardware to hardware interfaces within each processing element, as well as the hardware 
interfaces to the external environment by way of the system interconnect, local 
interconnects , internal interconnects or direct interfaces. This architecture shall [3] provide 
for three classes of processors: the EPs, SAPs and GAPs for which standardized interfaces 
shall [4] be required to be selected from a set of acceptable lower level interface standards. 

5.2.1 .1.2 Hardware Architecture 

The GAP architecture shall [1] be configured to provide hardware components to interface 
to a system interconnect, to interface to local interconnects, to process applications, perform 
BIT and optional components for other purposes as required by the system. The SAP 
architecture shall [2] be configured to provide hardware components for control, filtering, 
bus interface, BIT and other specialized purposes as required by the system. The EP 
architecture shall [3] be configured to provide hardware components for microcontrol, BIT, 
hardware handling and setup, and bus interface as required by the system. 
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Figure 5-4. Class 1 Hardware-to-Hardware Direct Interfaces 




a. The hardware architecture shall [4] provide communications from at least one of three 
levels of communications: Level 1, System Interconnects (e.g.. Fiber Data Distribution 
Interfaces - (FDDI)), Level 2, Local Interconnects (e.g., MIL-STD-1553 bus and RS-449 
links), and Level 3, Internal Interconnects (e.g., VME backplane). This is illustrated in 
Figure 5-4. 

b. Level 1 system interconnects shall [5] be implemented by high capacity networks or links 
providing communications between host platforms using techniques such as FDDI or by 
direct links between high data rate elements. 

c Level 2 local interconnects shall [6] be implemented by a combinations of buses and 
direct links for analog, discrete or serial communications between subsystem elements 
or components within one host platform. 

d. Level 3 internal interconnects shall [7] be implemented by a combination of backplane 
buses to connect devices such as circuit boards connected by VME or Futurebus+ 
backplanes and internal component links. 


The communications from sensors or effectors to EPs are only possible through direct links 
because the intention of the architecture is that embedded processors are those processors 
embedded in the sensor or effector hardware devices to minimize the communications 
latencies. 

5.2.1 .2 Generic Processing External Hardware Architecture 

The Generic Processing External Hardware Architectures shall [1] be defined as shown in the 
example in Figure 5-5. The architecture system interconnect represents the inter-subsystem 
connectivity, and can be implemented by a combination of one or more communications 
paths using point-to-point, ring, bus or other architecture designs. Typically, system 
interconnects such as core networks are implemented by lower level standards such as FDDI 
or Ethernet. Local interconnects provide the intra-subsystem connectivity for high speed 
data communications between processors within one subsystem. Typically, the local 
interconnects are implemented by lower level standards such as MIL-STD 1553B for local 
command and data buses, RS-488 for timing controls, and direct links for analog and 
discrete signals. The interface plugs shown represent the unique hardware interfaces which 
shall [2] be defined by standards. 
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SPACE DATA SYSTEM ARCHITECTURE 
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Figure 5-5. Generic Processing External Hardware Architecture and Interfaces for a Space Generic Open Avionics 

Architecture 







5.2.1 .2.1 GAP Architecture 

GAPs represent general purpose data processors. A GAP, if required, shall [1] be one of two 
forms: one for standard general purpose use [GAP(S)] and one for multiplexing and 
demultiplexing signals [GAP(M)]. Typically, GAP devices are used where slow response 
times (such as on the order of seconds to tens of seconds) are required. An example of a 
compliant implementation of GAP(S) processors is the Standard Data Processor in the Space 
Station Freedom program and the General Purpose Processing Element in the F-22 
program. An example of a compliant implementation of the GAP(M) is the Multiplexer - 
DeMultiplexer processor in the Space Station program. 

5.2.1 .2.2 SAP Architecture 

SAPs if required, shall [1] provide the special purpose processing which is usually needed in 
high power embedded computers and may be implemented by devices such as vector or 
associative processors, massively parallel data processors, or arithmetic coprocessors. 
Typically, SAP devices are used where response times (such as on the order of hundreds of 
milliseconds to a second) significantly faster than in a GAP are required. Examples include 
the associative and vector processors used in the F-22 program. 

5.2.1 .2.3 EP Architecture 

Within each sensor or effector, this architecture allows, but does not require, the placement 
of processors embedded in the sensor or effector unit. EPs if required, shall [1] be one of two 
forms: one for effector processing [EP(e)] and one for sensor processing [EP(s)]. EPs shall [2] 
provide the very high speed processing necessary to manipulate and convert analog data to 
digital data while performing some preprocessing on it to reduce the data rate to a more 
acceptable level for linkage back to the GAP(M). Typically, EP devices are used where very 
fast response times (such as on the order of milliseconds or less) are required. Where the 
data rate with the sensor or effector is acceptable to the GAP(M) and no other pre-processing 
is required, direct interface to the GAP(M) may be used. Sensors and effectors interface to 
the EP devices either through local communication interfaces or through direct links. 

5.2.1 .2.4 Lower Level Interface Standards 

Lower level interface standards shall [1] be selected for implementing system interconnects, 
local interconnects, GAP to EP direct links, GAP to S direct links, GAP to E direct links, EP to 
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S direct links, and EP to E direct links. User definable interfaces shall [2] be provided for the 
SAPs. Lower level video and graphics interface standards shall [3] be selected to define 
implementations for connecting the GAP devices to humans for development, operation 
and maintenance of the systems. 


5.2.1 .3 General Avionics Proces sor Internal Hardware Architecture 

The requirements for general purpose processing elements in a vehicle shall [1] be defined 
as shown in the GAP architecture presented in Figure 5-6. The generic hardware elements 
shown in the figure comprise the basic, generic hardware modular elements in the SGOAA. 
The processor may be configured as a GAP(S), GAP(M), EP(s) or EP(e) depending on the set 
of functions required by a specific application. The SAP is a special purpose case and may 
require functions not included in the generic processor function set such as vector or 
parallel processing. 

5.2.1 .3.1 GAP Function Set 

The GAP function set is a shopping list of modular functions which can be used to build the 
needed configuration. Each module shown provides a specific independently procurable 
service. Additional unique service functions may be added by defining additional modules. 
The actual implementation in hardware is interface standard, technology and detailed 
design dependent. System performance requirements for hardware modular elements shall 
[1] be a primary consideration in module selection to perform a specific function. System 
error processing and fault treatment requirements for hardware modular element BITE 
shall [2] also be considered in hardware modular element selection. Specific hardware 
interfaces that shall [3] be defined by lower level standards are shown in Figure 5-6. 

5.2.1 .3.2 Internal Interconnect Interface Standards 

Internal interconnect interface standards shall [1] be imposed to provide modularity with 
the capability for technology upgrades and multiple vendor sources of processing functions 
modules. Although only one internal interconnect bus is shown for the backplane in Figure 
5-6, the actual bus implementation may consist of multiple buses depending upon the 
specific application. Possible buses include data, time, test, and local memory. Multiple 
standards exist for all of these bus types. 
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5.2.1 .3.3 Lower Level Interface Standards 

Lower level interface standards as illustrated in Figure 5-6 shall [1] be selected for system 
interconnect, test and checkout system, mass memory, timing bus, discrete data, analog data, 
serial data, parallel data, local interconnect, video/graphics, audio and optional functional 
growth interfaces. For example, to implement the functions of the basic GAP(S) would 
require implementation of the system interconnect processing, application processing and 
local communications (e.g., local interconnect and I/O) processing functions of the GAP 
Hardware Architecture shown in Figure 5-6. A internal interconnect bus standard such as 
Future Bus Plus (FB+), VME or Pi Bus would be imposed as the backplane data bus 
standard. The backplane bus standard used in a specific architecture implementation might 
consist of one or more specific buses; separate buses are permitted for uses such as test and 
maintenance. 

5.2.2 CLASS 2 - HARDWARE-TO-OPERATING SYSTEM EXTENSION SOFTWARE 
DIRECT INTERFACE REQUIREMENTS 

Hardware to operating system extension software interfaces are shown in Figure 5-7. These 
interfaces shall [1 ] consist of the interfaces from the operating system extension, low level 
software or other software performing the same function (such as drivers in the OS, data 
system manager, etc.) to the hardware instruction set architecture (ISA) and register usage. 
With regard to the model, these interfaces are internal to each processing element. The 
hardware elements are grayed out to show that these elements are a repeat of the previous 
figure; the black elements represent the new capabilities and interfaces added by this 
interface class. This class shall [2] define the interfaces for low level software drivers that 
interact with the hardware for each of the processor types (EPs, SAPs, and GAPs). All the 
drivers for all processor types shall [3] be contained in a SD5S sub-architecture. 

5.2.2.1 Error Processing 

All types of error processing on data transmissions for flight or safety critical functions 
through the class 2 interface shall [1] be allowed except those employing retransmission. For 
those mission critical or service functions that have no hard deadline requirements, error 
processing employing retransmission shall [2] be allowed. 
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Figure 5-7. Class 2 Hardware-to-System Software Direct Interfaces 









5. 2. 2.2 System Services Software 

The system services software in the SDSS for the GAP shall [1] be organized into five 
categories. The categories shall [2] be the Data System Manager, Data Base Manager, 
Input/Output Data Services Manager, Operating System, and Network Services Manager. 
(See section 5.3 for interface service requirements.) The software drivers for the SAP shall 
[3] be organized into four categories: I/0)formatting, normalization, specialized processing 
interfaces, and local communications interfaces. The software drivers for the EP shall [4] be 
organized into four categories: built-in-test (BIT), hardware handler interfaces, local 
communications interfaces and microprocessor execution control. 


5.2.2.3 Hardware/Operatlnq System Extension Interfaces 

The hardware/operating system extension interfaces needed for the hardware to be accessed 
by low level software such as drivers shall [1] be defined as shown in Figure 5-8. The 
interfaces are shown in black and labeled, and everything else has been grayed out to 
highlight items of interest. 


5.2.3 CLASS 3 - OPERATING SYSTEM SERVICES SOFTWARE-TO-SOFTWARE 
(LOCAL) DIRECT INTERFACE REQUIREMENTS 

Operating system services software to other local software direct interfaces shall [1] be 
defined as the operating system interfaces shown in Figures 5-9. This definition consists of 
the I/O handler calling conventions and context switch conversions between the system 
software drivers on one processing element interfacing with one or more system software 
services to provide for local information exchange. Class 2 provided the software drivers to 
isolate the hardware. Class 3 provides the remainder of the direct operating system 
interfaces to local software services needed to operate the computer system. 


5 .2.3.1 Local Software Service Grouping 

All local software services shall [1] be grouped into the Data System Services (DSS) sub- 
architecture and shall consist of the Data System Manager, Data Base Manager, 
Input/Output Data Services Manager, Operating System, and Network Services Manager. 
Class 3 shall [2] provide the direct interfaces between the operating system services to other 
local data system services and applications for effective local interprocess communications 
and support. These interfaces are direct interfaces because they enable operating system 
service code to interact with software service code in other local entities. Although the 
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Figure 5-8. GAP to Hardware Drivers 
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Figure 5-9. Class 3 System Software-to-Software Direct Interfaces 




























operating system services are a subset of the DSS, they shall [3] also provide direct low level 
operating system service access not provided by the higher level DSS interface for those 
users requiring this type of interface. Class 3 interfaces shall [3] meet derived requirements 
based on the need of an application to support users. 

5 .2.3.2 Class 3 Flight. Safety and Mission Critical Interfaces 

For class 3 interfaces of flight, safety or mission critical functions with hard deadlines to 
either the Data System Manager or to Device Drivers, all types of error processing on data 
transmissions through the class 3 interface shall [1] be allowed except those employing 
retransmission. For those mission critical or service functions that have no hard deadline 
requirements, error processing employing retransmission shall [2] be allowed. For class 3 
interface to applications, no error processing across the interface shall [3] be allowed (that is, 
the data transmission itself is assumed to be error free). 


S.2.3.3 Class 3 Operating System Interfaces 

The operating system- to-system service software and applications software interfaces shall 
[1] be defined as shown in Figure 5-10. The interfaces are shown in black and labeled. Note 
that there are three possible types of interfaces: upward between the operating system 
services to any software application, upward to other data system services, and downward to 
the system extension software such as drivers within the operating system. Their grouping 
into class 3 facilitates design of operating systems and all interfaces needed to insure 
effective operating system performance. 

5.2.4 CLASS 4 - DATA SYSTEM SERVICES SOFTWARE-TO-DATA SYSTEM 
SERVICES SOFTWARE LOGICAL INTERFACE REQUIREMENTS 

Data system services software to data system services software interfaces shall [1] be defined 
as shown in Figure 5-11. This is the peer to peer interface of data system services software 
in one processing element (GAP, SAP or EP) interfacing with the system software in the 
same processing element or remotely to an external processing element to coordinate 
operations in a distributed environment. Since Classes 1 to 3 isolated the hardware and 
software services in each processor. Class 4 shall 12] provide the interface capability for 
services in one processor to interact with services in the same or another processor. Class 4 
interfaces shall [3] meet derived requirements based on the need of an application to 
support users in a multi-processing environment. 
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Figure 5-10. Operating System Interfaces 
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Figure 5-11. Class 4 System Software-to-System Software Logical Interfaces 




















5.2.4.1 Class 4 Critical Function Error Processing 

For flight critical functions, error processing shall [1] not be allowed on data transmissions 
across the class 4 interface. For safety critical, mission critical or service functions, error 
processing not employing retransmission shall [2] be allowed. 


5.2.4.2 Class 4 Data System Services Interfaces 

The DSS interfaces needed to support local operations and logical access to other GAP data 
system services shall [1] be identified as shown in Figure 5-12. The black-line interfaces are 
the primary interfaces between the local services. Local services and remote services shall 
[2] have a common logical architecture. For distributed processing systems, a circular 
interface between each service entity and itself shall [3] be defined as shown in Figure 5-12, 
since each service must be able to communicate with remote versions of itself in other 
nodes. Remote interfaces to the special avionics processor and the embedded processor 
services shall [4] also be defined and specified. 


5.2.5 CLASS 5 - DATA SYSTEM SERVICES SOFTWARE-TO-APPLICATIONS 
SOFTWARE (LOCAL) DIRECT INTERFACE REQUIREMENTS 

DSS software to applications software interfaces shall [1] be defined as shown in Figure 5-13. 
This is the direct interface within a processing element between the application software 
and the DSS software (language bindings/specification) to allow provision of needed 
services. Since Classes 1 to 4 isolated the hardware and software services in all the 
processors. Class 5 shall [2] provide the interface capability for services in any processor to 
interact with an application executing in the processor. Class 5 interfaces shall [3] meet 
derived requirements based on the need of an application to support users in a multi- 
processing environment. 



5.2.5.1 Class 5 Error Processing 

Error processing on data transmissions across the class 5 interface shall [1] not be 
allowed. Transfer of error processing results over the class 5 interface to Onboard 
Health Management processing shall [2] be allowed. 
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Figure 5-12. SDSS Services to Other or Remote Services 
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Figure 5-13. Class 5 System Software-to-Applications Software Direct Interfaces 





5. 2. 5. 2 Services to Applications Interfaces 


The DSS to applications interfaces shall [1] be defined as shown in Figure 5-14. The 
applicable interfaces are shown in black and labeled, and everything else has been grayed 
out to highlight items of interest. There shall [2] be a standard access interface to the data 
system services, which is a function of the service and independent of any one application 
The Input /Output Data Services manager shall [3] be capable of providing access to other 


services as well as directly to the application or sensor providing the source of data. The 
data system manager shall [4] be capable of providing control interfaces to other control 


subsystems. 


5.2.6 CLASS 6 - APPLICATIONS SOFTWARE-TO-APPLICATIONS SOFTWARE 
(LOGICAL) INTERFACE REQUIREMENTS 

Applications software to applications software interfaces shall [1] be defined as shown in 
Figure 5-15. This shall [2] be a peer to peer information exchange and coordination interface 
between application software modules. Applications shall [3] not communicate directly. All 
application to application software communication shall [4] be implemented by use of 
system services software. All communication shall F5] be through a Class 5 standard 
interface to System Services to provide the direct communications path between 
applications. This interface may be between applications within a processing element or 
between applications in separate processing elements. The grayed out parts of the figure 
represent the material covered in Classes 1 to 5, the black parts of the figure are the new 
interface definitions added in Class 6. Since Classes 1 to 5 isolated the hardware, software 
services and applications in any processor. Class 6 shall [6] provide the interface capability 
for an application in any processor to interact with another application executing in any 
processor. Class 6 interfaces shall [7] meet user and derived requirements based on the need 
of multiple applications to support users in a multi-processing environment. 


5.2.6.1 Class 6 Error Processing 

Error processing on data transmissions across the class 6 interface shall [1] not be allowed. 
Transfer of data between Onboard Health Management entities shall [2] be allowed. 


5.2.6.2 Applications to Applications Interfaces 

Applications to Applications interfaces may also include interfaces between applications in 
two different systems or vehicles. System A applications software to system B applications 
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Figure 5-14. Services to Applications Interfaces 
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Figure 5-15. Class 6: Applications Software-to-Applications Software Logical Interfaces 



software interfaces shall [1] be defined as shown in Figure 5-16. The grayed out parts of the 
figure represent the material covered in Classes 1 to 6 (within one system), the black parts of 
the figure are the unique interfaces that are provided by Class 6 for inter-system interfacing. 
Since Classes 1 to 5 isolated the hardware, software services and applications in any system. 
Class 6 shall [2] provide the interface capability for an application in one system to interact 
with an application executing in another system. Class 6 interfaces shall [3] meet user and 
derived requirements based on the need of multiple applications to support users in a 
multi-system environment. Class 6 interfaces shall [4] be defined to meet the overall 
mission and operational control requirements across multiple facilities and vehicles. 


5.3 DATA SYSTEM SERVICE ARCHITECTURAL REQU IREMENTS 

The DBS architecture shall [1] include capabilities drawn from up to five categories of 
services: the Data System Manager, Data Base Manager, Input/Output Data Services 
Manager, Operating System, and Network Services Manager, as shown in Figure 5-17. 
Interfaces from external entities to the DSS shall [2] be as shown. Control of the data system 
resources shall [3] flow through the Data System Manager (D5M) to insure coordination of 
the system configuration at all points for reliability. Data shall [4] flow through the 
Input/Output Data Services Manager (IOSM). Crew display and control (D&C) shall [5] be 
capable of operating through at least the IOSM and the DSM to insure at least one normal 
and one alternative path for direct low level system command and control by the crew. 
Similarly, operations control shall [6] be capable of operating through at least the IOSM and 
the DSM to insure at least one normal and one alternative path for direct low level system 
control by the ground OTrnission control. Access by applications will be as required by the 
system requirements documents. 

The DSS architecture shall [7] provide options for at least the services as organized and 
shown in Figure 5-18. Implementation requirements for such services will depend on the 
system requirements documents. 

5.3.1 INPUT/OUTPUT DATA SERVICES MANAGEMENT 

The Input/Output Data Services Manager shall [1] provide all interface to the system users 
for data processing and data communication services. Services to be provided to the users 
shall [2] be derived directly from user requirements. The input/output data services 
management shall [3] include at least requirements for standard services data acquisition, 
standard services data distribution and reports generation. 
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Figure 5-16. Class 6 System A Software-to-System B Software Logical Interfaces 
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Figure 5-17. Data System Services Architectural Interface Elements 




5-31 


Figure 5-18. Interface Service Elements 



5.3.2 DATA SYSTEM MANAGEMENT 

The Data System Manager shall [1] provide the housekeeping and control services for the 
SDSS. Command and control service requirements shall [2] be derived directly from user 
needs. Data system management shall [3] include at least requirements for configuration 
management, timing service control, initialization startup and reconfiguration, error 
processing, error recovery, fault treatment and reporting of health status to onboard health 
management. The DSM shall [4] execute under the Operating System. There is a command 
and control interface to the crew and to the SOCS. Command and control service 
requirements are derived directly from user needs. 

5.3.3 NETWORK SERVICES MANAGEMENT 

The NSM shall [1] provide for peer-to-peer communication between applications on 
distributed processing elements communicating over the SDSS system interconnect which 
require use of network communications between applications in distributed processing 
environments. The network services management shall [2] include at least requirements 
for network services, network management, remote operation, network directory service, 
and network association control. 

5.3.4 DATA BASE MANAGEMENT 

This entity shall [1] provide services to the SDSS subsystems and application users for the 
management of structured data files, file transfers and file redundancy management. The 
data base management shall [2] include at least requirements for file services, distributed file 
transfer services, file transfer access and management, and node directory. All communi- 
cation with and requests for services from the DBM shall [3] be through the IOSM. 

5.3.5 OPERATING SYSTEM 

The OS shall [1] provide the layer of SDSS software that isolates other services as well as 
application software from the data processing hardware element. The OS shall [2] provide 
management, allocation, and deallocation of the processor, memory, timing and I/O 
processing resources for application and service software and hardware that is independent 
of the mission. The operating system shall [3] offer at least open standard OS services such 
as an OS kernel and/or a run time environment (RTE) and OS/RTE extensions. Resource 
allocation and control that is mission dependent shall [4] be treated as an application. 

A bare machine user may interface directly with the Run Time Environment (RTE). 
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6. NOTES 


(This section contains information that may be helpful, but is not mandatory) 

6.1 AVIONICS SYSTEM NOTES 

6.1.1 AVIONICS GENERAL 

Avionics provide for information acquisition, transmission, and storage of analog or digital 
signals and include the sensors, intra-platform communications, processing hardware, 
software and subsystems, data storage, human-machine interface subsystems, and response 
actuator controls used in the vehicle. 


6.1.2 MODES 


Modes govern how the system operates in response to human commands. Mission ready 
mode means the system has all elements working as specified or "green". Operationally 
ready mode means the system can function but can not accomplish a desired mission, for 
instance wh en an aircraft is configured for a reconnaissance mission but is needed for a 
bombing mission, or when a spacecraft is can be launched but has no payload installed. 
Degraded mode means the system is "soft broke", but can perform a subset of its required 
functions. An example is when an aircraft radio is not working so not all functions can be 
performed but the aircraft can still fly and drop bombs. Red-tagged mode means that the 
system cannot operate at all, for instance when an aircraft fuel system is polluted or a wheel 
is broken on the ground. 




6.1.3 ARCHITECTURE INTERFACE MODEL 



The Architecture Interface Model" is summarized in Figures 5-3 and 6-1. Figure 5-3 


presented the architecture reference model, and Figure 6-1 presents an overlay of the 
reference model on the generic avionics structure assembled in this standard. Both figures 
also show the relationships of this architecture interface model to the POSIX interfaces. 


6.2 REQUIREMENTS NOTES 

6.2.1 DATA PROCESSING SUBSYSTEM 

Data processing subsystem requirements are inherited onto lower level subsystems. A data 
processing subsystem is setup and controlled by a runtime operating system. 
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6.2.2 INTERSYSTEM APPLICATIONS INTERFACE 

Intersvstem applications interface requirements a ddress logical requirements of the user 
across the interface. 


6.2.3 CONTROL SUBSYSTEM 

Control subsystem requirements are inherited onto lower level control subsystems. 

6.2.4 MODULAR ARCHITECTURE 

Modular architecture requirements changes should not cause disproportional changes in 
the design, and design changes should be limited to one or a few design modules. 
Requirements changes should not affect the architecture of the system, unless the change is 
one for the architecture directly. 


6.2.5 DIRECT INTERFACE 

Direct interface requirements are normally a design issue unless the physical 
implementation has implications for the logical vise or need for data, only then should the 
direct implementation be specified as a requirement. For instance, a service such as a 
Reports Generator getting data from a Data Base Manager might not need to know the inter- 
network addressing of the Data Base Manager, but the Network Manager providing the data 
would need to know the routing requirements of the hardware services. 

6.3 REQUIREMENTS CHARACTERISTICS DESIRED 
6.3.1 ROBUSTNESS 

Robustness must enable a system to operate in conditions not originally foreseen by the 
specification without catastrophic failures, without exhibiting behavior that disturbs the rest 
of the system, by failing (if necessary) in a "graceful" manner by terminating cleanly and 
safely. 


6.3.2 SYSTEM SERVICES SOFTWARE 

System services software must have common and standardized interfaces serving many 
applications. 
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6.3.3 SERVICE FUNCTIONS 


Service functions are usually widely replicated in support of many control or data 
processing subsystems. This wide replication of functionality is a key determining 
characteristic in defining an individual process as a service in this methodology. Services 
are critical to system operation, not to mission or vehicle operation per se. An example of a 
service function is a Report Generator since many applications and control subsystems 
must generate reports; here, they call on the report generator service which knows how to 
look up the table defining the applications/control report, how to format the format for 
completion, how to find the data to fill the report fields with, and how to route the report 
for distribution based on a predefined distribution list. High level standard services are 
services such as timing, distributed data handling and fault tolerance, which may have 
different needs when viewed as a multi-processing system than when considered as a single 
processor system. 

6.3.4 TAILORING 

Tailoring of the SGOAA may result in subsets of requirements applicable to a mission or 
program, but the resulting system must retain architectural interface compatibility. 

6.3.5 SYSTEM CHARACTERISTICS 

System characteristics that determine the nature and requirements for a system hardware 
architecture are the number of processors, their type and topology, the speed and size of 
shared memory available, the local memory of each, the bandwidth and access to 
communications media, and the interfaces available for use by people, applications and 
platform software services in the hardware. 

6.3.6 ONBOARD HEALTH MANAGEMENT 

Onboard health management facilitates tradeoffs between requirements for and design of 
reliability, maintainability, error processing, and fault treatment. Compliant architectures 
should also facilitate defining requirements for and interactions between health 
management, logistics, supportability, and safety management. 
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6.4 ARCHITECTURAL CHARACTERISTICS DESIRED 

6.4.1 SYSTEM SOFTWARE ARCHITECTURE 

A system software architecture must describe the set of system functions performed by the 
applications software, and the structure of the platform software services that enable the 
applications software to perform their tasks. The functionality described by the system 
software architecture are the tasks which are required of the system to meet the needs of 
operational users. 

6.4.2 APPLICATION PLATFORM 

The a pplication platform provides services at its interfaces that, as much as possible make 
the specific characteristics of the platform transparent to the application. 

6.4.3 APPLICATION PROGRAM INTERFACE 

The API is primarily in support of application portability, but system and application 
interoperability are also supported by the communications API. 

6.4.4 ARCHITECTURE LOCATION INDEPENDENCE 

Architecture location independence is desirable, meaning an architecture compliant with 
this standard should be independent of whether control functions are implemented 
onboard the vehicle or offboard the vehicle (e.g., in support control facilities). 

6.4.5 FAULT TOLERANCE TRANSPARENCY 

Fault tolerance transparency is desirable, meaning applications in an architecture compliant 
with this standard should not require knowledge of the redundancy of its platform or its 
direct interfaces. 

6.4.6 ADAPTABLE REDUNDANCY 

Adaptable redundancy is desirable, meaning that an architecture compliant with this 
standard should allow more than one configuration of the architecture to provide different 
levels of redundancy. This allows another level of commonality beyond that of hardware 
and software modules. 
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6.5 DIRECT AND LOGICAL INTERFACE NOTES 

6.5.1 CLASS 2 DIRECT INTERFACE 


The Class 2 Hardware-to-System Software Direct Interface drivers are (obviously) hardware 
dependent, but this enables the architecture to begin partitioning out of the hardware 
dependencies, which is a key in providing for technology upgradability in the future. 

6.5.2 HEALTH MANAGEMENT INTERFACE 

Note that interface drivers specifically defined for health monitoring are not required. Each 
required driver will collect all data associated with its hardware element and format it for 
conveyance to the appropriate operating system interfaces; if health monitoring capabilities 
have been implemented in the associated hardware, then this data will be collected along 
with all other data. 

6.5.3 CLASS 4 LOGICAL INTERFACES 

Class 4 System Software-to-System Software Logical Interfaces provide the interface 
capability for services in one processor to interact with services in the same or another 
processor. They are the heart of multi-processor capability needed in modem space avionics 
systems. EP services can interact with SAP and GAP services; SAP services can interact with 
GAP services; GAP services can interact with EP and SAP services and other GAP services. 
These interfaces are logical interfaces because the service originating data is interacting with 
the service that will use the data (i.e., that will transform the data into another form for a 
purpose). 

6.5.4 CLASS 5 DIRECT INTERFACES 

Class 5 System Software-to-Applications Software (Local) Direct Interfaces provide the 
capability for services in any processor to interact with an application executing in the 
processor. Applications can operate in any GAP, with potential partitioning of an 
application across multiple GAPs. Similarly, applications can operate in any SAP or any EP. 
These Class 5 interfaces are direct interfaces because the applications software code is 
interacting with the service software code. 




6.5.5 CLASS 6 LOGICAL INTERFACES 

The Cl a ss 6 Applications Software-to- Applications Software (Logical) Interfaces are logical 
interfaces because the application originating data is not directly interacting with 
applications that will use the data. Class 6 interfaces are also the interface for exchange of 
information between the space avionics system and another avionics system for overall 
command and control. This interface is at the mission level and, may be an information 
exchange between the ground or between separate space vehicles. 


Class 6 also provides the basic multi-system capability to meet multiple actual user 
requirements in multiple systems, facilities or vehicles. Applications can operate in any 
system's processor (e.g., the Mission Control Center GAP or workstation) to cooperate with 
applications in another system’s processor (e.g., the Lunar Transfer V ehicle GAP). 

6.6 IMPLEMENTATION CHARACTERISTICS 

In implementation, tailoring of the generic architecture to the unique requirements of the 
mission and system application is critical to successful use of this architecture. Profiles need 
to be applied. Such usage must recognize the scaleability, recursiveness and interaction 
between target and development environments in order to take full advantage of the utility 
of this architecture. 

6.6.1 ARCHITECTURE SCALEABILITY 

The generic system architecture model can be scaled to apply to the size and definition of 
system being used in any type of hardware/ software processing system. It is equally 
applicable to systems at the vehicle level, rack or black box level, module or board level, or 
chip level, as shown in Figure 6-2. In this figure, examples of a system interconnect, local 
interconnect and internal interconnect change as the scale of system application changes. 
The use of embedded processor, general avionics processor and special avionics processor 
also changes. While only intended as an example, this figure makes clear that when two 
more engineers are applying the this architecture to a specific project, mission or system, 
great care must be taken to insure all discussions reference the same level of "system". 

6.6.2 ARCHITECTURE RECURSIVENESS 

The generic architecture interface model can be recursively applied to different usages of 
layers (i.e., hardware, drivers, OS, etc.) between the SGOAA classes in the architecture. As 
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Figure 6-2. The Generic System Architecture Model Is Scaleable 



shown in Figure 6-3, from an external view, hardware such as an ethemet board is a 
monolithic block. However, from within the block, ethemet "hardware" may consist of a 
microcosm of the entire interface model with board drivers, a OS kemel/RTE, some 
ethemet services and some ethemet processing applications all resident on the board. All 
of these microcosmic elements are transparent to an outside user passing through the 
interface. 

6.6.3 ARCHITECTURE TARGET DEVELOPMENT 

The architecture applies equally to any hardware/ software processing system. In the 
example shown in Figure 6-4, it applies to a development environment, where 
development software such as a compiler is an application, which must have knowledge of 
the host, the target and the programming language being used. Within the development 
environment, there are services, OS elements and drivers. The target code is operated on by 
the development environment and transferred upon completion to the target hardware to 
execute. From the view of the target environment, this development environment is 
transparent. 

6.7 TERMINOLOGY NOTES 

In the space systems avionics arena, a data system i s terminology used to refer to the set of 
operating system elements and supplementary or common services controlling processing 
resources in a host platform. This is similar to and includes the terminology system 
executive a nd distributed executive as used in PAVE PILLAR, global executive as used in 
parts of the F-22 Program, or common system services (e.g., an operating system) as used 
often in POSIX and other parts of the aircraft avionics arena. This standard differentiates 
between data system and data system services, in that a data system includes data system 
services, command processing, and other common capabilities (see Space Data System and 
Space Data System Services definitions in Section 3.1). 
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Figure 6-3. The Architecture Interface Model is Recursive 
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Figure 6-4. The Interface Model Applies to Target and Host Development Environments 











6.8 PURPOSE OF PROFILES 

As described in [POSIX91], profiles define the combinations of base standards and profiles 
(i.e., templates) for the purpose of: 

• Identifying the baseline standards, together with appropriate classes, subsets, options, 
and parameters, that are necessary to at least accomplish interoperability, portability 
and other identified capabilities. 

• Providing a system of referencing the various uses of baseline standards that is 
meaningful to both users and suppliers 

• Enhancing the availability for procurement of consistent implementations of 
functionally defined groups of baseline standards that are expected to be the major 
components of real applications systems 

• Promoting uniformity in the development of conformance tests for systems that 
implement the functions associated with the profiles 
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